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Abstract. We explore a transformational approach to the problem of 
verifying simple array-manipulating programs. Traditionally, verification 
of such programs requires intricate analysis machinery to reason with 
universally quantified statements about symbolic array segments, such 
as “every data item stored in the segment A[i] to A [j] is equal to the 
corresponding item stored in the segment B [i] to B [j] .” We define a simple 
abstract machine which allows for set-valued variables and we show how 
to translate programs with array operations to array-free code for this 
machine. For the purpose of program analysis, the translated program 
remains faithful to the semantics of array manipulation. Based on our 
implementation in LLVM, we evaluate the approach with respect to its 
ability to extract useful invariants and the cost in terms of code size. 


1 Introduction 

We revisit the problem of automated discovery of invariant properties in simple 
array-manipulating programs. The problem is to extract interesting properties 
of the contents of one-dimensional dynamic arrays (by dynamic we mean arrays 
whose bounds are fixed at array variable creation time, but not necessarily at 
compile time). We follow the array partitioning approach proposed by Gopan, 
Reps, and Sagiv [9] and improved by Halbwachs and Peron [11], This classical 
approach uses two phases. In a first phase, a program analysis identifies all 
(potential) symbolic segments by analyzing all array accesses in the program. 
Each segment corresponds to an interval Ik of the array’s full index domain, but 
its bounds are symbolic, that is, bounds are index expressions. For example, the 
analysis may identify three relevant segments I\ = [0, . . . , i — 1], I 2 = [*], and 
I 3 = [i + 1, . . . , n — 1]. After this the original array A is considered partitioned 
into segments Ai k corresponding to the identified segments and each segment is 
replaced with a summary variable a*. In the second phase, the analysis aims at 
discovering properties ip(ak) on each summary variable ak such that 
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By partitioning arrays into segments, the analysis can produce stronger separate 
analyses for each segment rather than a single weaker combined result for the 
whole array. In particular, we can identify singleton segments ( Aj 2 in the ex- 
ample) and translate array writes to these as so-called strong updates. A strong 
update benefits from the fact that the old content of the segment is eliminated by 
the update, so the new content replaces the old. For a segment that may contain 
multiple elements, an assignment to an array cell may leave some content un- 
changed, so a weak update must be used, that is, we must use a lattice-theoretic 
“join” of the new result and the old result associated with l. 

Although very accurate, array partitioning methods have their drawbacks. 
Partitioning can be prohibitively expensive, with a worst-case complexity of 
0(n!), where n is the number of program variables. Moreover, partitioning must 
be done before the array content analysis phase that aims at inferring invariants 
for the form (1), which could be less precise than doing both simultaneously [5]. 
To mitigate this problem, the index analysis, used to infer the relevant symbolic 
intervals, is run twice: once during the segmentation phase and again during the 
array content analysis, which needs it to separate the first fixed point iteration 
from the rest. In the more sophisticated approach of Halbwachs and Peron [11, 
16], the transfer functions are much more complex and a concept of “shift vari- 
ables”, representing translation (in the geometric sense) of segments. This is not 
easily implemented using existing abstract interpretation libraries. 

Contribution. We present a program transformation that allows scalar analysis 
techniques to be applied to array manipulating programs. As in previously pro- 
posed array analyses [9, 11, 16], we partition arrays into segments whose contents 
are treated as sets rather than sequences. To maintain the relationship among 
corresponding elements of different arrays, we abstract the state of all arrays 
within a segment to a set of vectors, one element per array. Thus we transform 
an array manipulating program into one that manipulates scalars and sets of 
vectors. A major challenge in this is to encode the disjunctive information car- 
ried by each array segment. We propose a technique that splits basic blocks. It 
has been implemented using the LLVM framework. 

Importantly, a program transformation approach allows the separation of 
concerns: existing analyses based on any scalar abstract domains can be used 
directly to infer array content properties, even interprocedurally. While other ap- 
proaches lift a scalar abstract domain to arrays by lifting each transfer function, 
our approach uses existing transfer functions unchanged, only requiring the ad- 
dition of two simple transfer functions easily defined in terms of operations that 
already exist for most domains. The approach is also parametric in the granu- 
larity of array index sets, ranging from array smashing [2] to more precise (and 
expensive) instances. When we go beyond array smashing, the transformational 
approach inherits the exponential search cost present in the Halbwachs/Peron 
approach, as for some programs P, the transformed programs P' are exponen- 
tially larger than P. However, for simple array-based sort/search programs [9, 
11], a transformational approach is perfectly affordable, in particular as we can 
capitalize on code optimization support offered by the LLVM infrastructure. 
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I — > vi = constant \ vi = o « 2 | vi = V2^U3 | A 
A — > vi = arr[v 2] | arr[vi] = W2 

J — >■ If (U1IXIU2) labeh label 2 | Jmp label \ error \ end 
B ->■ label : I* J 

P B+ 


Fig. 1 . A small control-flow language with array expressions 



Fig. 2 . (a) An array program fragment and (b) the corresponding set-machine program. 

2 Source and target language 

Our implementation uses LLVM IR as source and target language. However, as 
the intricacies of static single-assignment (SSA) form obscure, rather than clarify, 
the transformation, we base our presentation on a small traditional control flow 
language, whose syntax is given in Fig. 1 . We shall usually shorten “basic block” 
to “block” and refer to a block’s label as its identifier. 

Source. Each block is a (possibly empty) sequence of instructions, followed by 
a (conditional) jump. Arithmetic unary and binary operators are denoted by 
o and o respectively, and logical operators by txi. We assume that there is a 
fixed set of arrays {Ai, . . . , A*,}, which have global scope (and do not overlap in 
memory). The semantics is conventional and not discussed here. Fig. 2 (a) shows 
an example program in diagrammatic form. 

Target. The abstract machine we consider operates on variables over two kinds 
of domains: standard scalar types, and sets of vectors of length fc, where k is 
the number of arrays in the source. The scalar variables represent scalars of the 
source program, including index variables, as well as singleton array segments; 
sets of vectors represent non-singleton segments of all extant arrays. Let V be the 





Instructions I — » vi = constant \ vi = o u 2 | vi = u 2 o V3 | S 

Set operations S — »■ Si = nondet-subset(,S' 2 ) | <51 = S2 U S3 | (vi, ■ ■ . , Vk) = nondet-elt(Si) 

Jumps J — > If (viMsj) label 1 label 2 | Jmp label \ error \ end 

Blocks B — > label : I* J 

Programs P — > B + 

Fig. 3. Control-flow language for the set machine. 

^[Si = S 2 U S 3 ] (a, p) = (a, p[Si n- p(S 2 ) U p(S 3 )]> 

S^\Si = nondet-subset(S 2 )] (a, p) = (o, p[Si s]),s C p(S 2 ),s A 0 
=^[(14 , . .. ,Vk) = nondet-elt(Si)] (cr, p) = (ct[ui *1, . . . , Vk Xk],p), (xi, ■ - - ,Xfc) € p(Si) 

Fig. 4 . Semantics for set manipulating operations. 


set of scalar variables and S be the set of vector set variables. The runtime state 
of the machine is given by a pair (cr, p) consisting of a variable store a : V — > Z, 
and a set store p : S — » V(Z k ). 

A control flow language for set machine programs is given in Fig. 3. Arith- 
metic and logical operations affect only the variable store cr; the semantic rules 
for these operations are standard. The set machine also has set operations union 
(U), subset (nondet-subset) and element_of (nondet-elt). Fig. 4 gives their seman- 
tic rules, distinguishing scalar variables v and (vector) set variables S. 

The union update S 1 = S 2 U S 3 maps S 1 to the union of values of S 2 
and S 3 . The subset and element operations are non-deterministic: executing 
Si = nondet-subset^) assigns to Si some non-empty subset of elements from 
S2, but makes no guarantee as to which elements are selected. Similarly, the el- 
ement operation (vi, . . . ,Vk) = nondet-elt(S'i) nondeterministically selects some 
element of vector set Si to load into vi , ,Vk- 

Translation. Fig. 2(a)’s program scans an array for the first occurrence of value 
x, assumed to occur in A. The constraint A[i] = x A V k £ [0,*) (A[k\ ^ x) is 
the desired invariant at tail. A corresponding array- free program is given in 
Fig. 2(b). The example illustrates some key features. Each contiguous array 
segment is represented by a set variable Aj. Each original block is duplicated 
for each feasible ordering of interesting variables. In the initial ordering (0 = i) 
the only interesting segment is A [0] , represented as the singleton a 0 ; the read 
v = A[i] is replaced by an assignment v = do . At guard 0< \ A[i] is represented 
by ai so the read is replaced by v = a\. When i is updated at body 0=l , the 
previous singleton ao becomes part of an “aggregate” segment A[0, i— 1]. We then 
transform singleton ao to set Ao and introduce a new singleton ai (representing 
A[i\ in the updated ordering). Similarly, when we update i in body 0< *, segments 
A[0,i — 1] and A[i\ are merged (yielding A 0 = A 0 U {ai}), and a new singleton 
ai is introduced. Consider the resulting concrete set-machine states. At tail n ~*, 
we have a 0 = x, corresponding to A[0] = x in the original program. At tail 0<l , 
we find x (j Ao and ai = x. These correspond, respectively, to array invariants 
W € [0, i — 1] . Aft] 7 ^ x and Afi] = x in the original program. 



3 From scalar to set machine transfer functions 


We now show how to lift a scalar domain for use by set machines. Essentially, we 
use a scalar variable to approximate each component of each set; approximation 
of set-machine states can then be obtained by grouping states by values of the 
(original) scalar variables. Essentially, we approximate a set-machine state (a, p) 
with set variables {Si, . . . , S m } by a set of scalar states {Si, ... , S^} represent- 
ing the possible results of selecting some element from each set: 

a°((o-,p)) = {crU {Si >->• 2 / 1 , . . .,S^ y m } \ y 1 G p(Si), . ..,y m G p(S m )} 

Transfer functions for set operations then operate over the universe of possible 
states, rather than apply element-wise to each state. 

Example 1. Consider a program with one scalar variable x, and one set variable 
S, with initial state ({a; 0}, {S >— > {1, 2}}). If we introduce a scalar variable y 

that selects a value from S via a we have two possible states: 

({* t-t 0, y i->- 1},{S !->• { 1 , 2 }}) 

({a : 1 > 0, a/ 1 — ;■ 2}, {S i — >• {1,2}}) 

If we represent S by scalar variable S°, we have initial states ({a: 0, S° 1 }) 

and ({a: >-»■ 0,S° 2}). When we wish to select a value for y, it is chosen 

nondeterministically from the possible values of S°, resulting in the states: 

({a: i — 0, 3 / 1 — >• 1, 5”° i — >• 1}), ({a; i— >■ 0, y 1 , S° H > 2}) 

({a: n- 0, y i — > 2, S° i— > 1 }), ({a: i — >■ 0, z/ 1 — 2, iS ' 0 i — >- 2}) 

If we group states with equal values of x and y, we can see that these correspond 
to the final states of the original set-machine fragment. □ 

Note that this is an (over-)approximation. We can only infer the set of values that 
may be elements of S — this representation cannot distinguish sets of elements 
which may occur together, nor the cardinality of S. For example, assume we 
have possible set-machine states (0, {5 >->• {1}}) and (0, {S i->- {2}}). The scalar 
approximation is ({S ' 0 1}, {S° 2}) which covers the feasible set-machine 

states, but also includes (0, {S {1, 2}}), which is not feasible. More generally, 
if the set <p of concrete states allows sets S Xi, ... ,S Xk, we have: 

VI(ICIiU...Ult^(5^I)G7o a{<p)) 

Consider a (not necessarily numeric) abstract domain A, with meet (n), join (LI) 
and rename operations, as well as a transfer function & : I — > A — > A for the 
scalar fragment of the language. The rename operation constructs a new state 
where each variable a is replaced with y-i (then removes the existing bindings 
of Xi). Formally, the concrete semantics of rename is given by 

2/1 ^ cr( aq), ,..,y k ^>- a(x k ), 

X\ !->• *, . . , f x k e-)- * 

For each set variable S, we introduce k scalar variables [s 1 , . . . , s k ] denoting the 
possible values of each vector in S. We then extend & to set operations as shown 
in Fig. 5. 


rename(er, [aq ; . . . ,x k ], [y u . . .,y k ]) = a 



&\Si = nondet-subset(S , 2 )] ‘z 3 

&[Si =s 2 u s 3 ] P 

^l(vu ...,Vk) = nondet-elt(Si)] <p 


P n rename (<p, [4, • • • , s% [si, , Si]) 
/ <P]Si = nondet-subset^)] 
yu &]Si = nondet-subset(5 , 3)] p J 
<p n rename (<p, [si, . . . , sfj, [uj, . . . , t>i]) 


Fig. 5. Extending the transfer function for scalar analysis to set operations 


4 Orderings 

The transformation relies on maintaining a single ordering of index variables at 
each transformed block. We now discuss such total orderings. 

Our goal is to partition the array index space (— 00 , 00 ) into contiguous re- 
gions bounded by index variables. For index variables i and j, we need to be 
able to distinguish between the cases where i < j, i = j and i > j. However, 
this is not enough; if we assign A[i\ = x, but only know that i < j, we cannot 
distinguish between the cases i = j — 1 (every element between i and j is x) and 
i < j — 1 (there are additional elements with some other property). So, for index 
variables i and j, we choose to distinguish these five cases: 


i + 1 <j 


i + 1 = j 


i=j 


i=j + 1 


i> j + 1 


For convenience in expressing these orderings, we will introduce for each index 
variable i a new term i + denoting the value i + 1, and for a set of index variables 
I we will denote by I + the augmented set I U {u + | v € I}. We can then define a 
total ordering of a set of index variables I to be a sequence of sets [B \, . . . , Bk\, 
B s C 1+ , such that the B s ’s cover 1+ , are pairwise disjoint, and satisfy * € B s 
i+ e B s+1 . 

The meaning of the ordered list 7 r = [Bi, B 2 , ■ ■ ■ , Bk] is parameterised by 
the value of program variables involved, that is, it depends on a store cr. The 
meaning is: |7 t](ct) = 

(Ve, e! e B s (a(e) = cr(e')) A Ve G B s Me! £ B t (s < t — > a(e) < cr(e'))) 

S,t(z[l..k] 


An ordering 7r (plus virtual bounds {— 00 , 00 }) partitions the space of possible 
array indices into contiguous regions, given by [cr(e), cr(e')) for e € Bj, e' G Bi + 
For any index variable i, a segment containing i + in the right bound is necessarily 
a singleton segment; all other segments are considered aggregate. 

When a new index variable k enters scope, several possible orderings may 
result. Fig. 6(c) gives a procedure for enumerating them. When an index variable 
k leaves scope, computing the resulting ordering consists simply of eliminating 
k and k + from tt, and discarding any now-empty sets. Assignment of an index 
variable is handled as a removal followed by an introduction. 3 

3 If the assigned index variable appears in the expression, we assign the index to a 
temporary variable, and replace the index with the temporary in the expression. 








We can discard any ordering that arranges constants in infeasible ways, such 
as 4 < 3. If we have performed some scalar analysis on the original program, we 
need only generate orderings which are consistent with the analysis results. 


5 The transformation 

We now detail the transformation from an array manipulating program to a 
set-machine program, with respect to a fixed set of interesting segment bounds. 
Section 6 covers the selection of these bounds. Intuitively, the goal of the trans- 
formation is to partition the array into a collection of contiguous segments, such 
that each array operation uniquely corresponds to a singleton segment. Each 
singleton segment is represented by a tuple of scalars; each non-singleton seg- 
ment is approximated by a set variable. There are two major obstacles to this. 
First, a program point does not typically admit a unique ordering of a given 
set of segment bounds; second, as variables are mutated in the program, the 
correspondence between concrete indices and symbolic bounds changes. 

The transformation resolves this by replicating basic blocks to ensure that, at 
any program point, a unique partitioning of the array into segments is identifi- 
able. Any time a segment-defining variable is modified, introduced or eliminated, 
we emit statements to distinguish the possible resulting partitions, and duplicate 
the remainder of the basic block for each case. For each partition, we also emit 
set operations to restore the correspondence between set variables and array 
segments, using nondet-elt and nondet-subset when a segment is subdivided, 
and U, when a boundary is removed, causing segments to be merged. This way 
every array read/write in the resulting program can be uniquely identified with 
a singleton segment. As singleton sets are represented by tuples of scalars, we 
can finally eliminate array operations, replacing them with scalar assignments. 

In the following, we assume the existence of functions next_block, which allo- 
cates a fresh block identifier, and push_block, which takes an identifier, a sequence 
of statements and a branch, and adds the resulting block to the program. We 
also assume that there is a mutable global table T mapping block identifier and 
index variable ordering pairs (id, 7 r) to ids, used to store previously computed 
partial transformations, and an immutable set X of segment bound variables and 
constants. The function get_block takes a block identifier, and returns the body of 
the corresponding block. The function vars returns the set of variables appearing 
lexically in the given expression. The function find_avar gives the variable name 
to which a given array and index will be translated, given an ordering. 

Fig. 6 gives the transformation. Procedure transform takes a block and trans- 
forms it, assuming a given total ordering 7r of the index variables. It is called 
once with the initial block of each function and an ordering containing only the 
constants in the index set. As there are finitely many (id, 7 r) combinations, and 
each pair is constructed at most once, this process terminates. 

The core of the transformation is done by a call to transform_body(B, 7 r, id, ss ). 
Here B is the portion of the current block to be transformed and 7r the current 
ordering, id and ss hold the identifier and body of the partially-transformed 



% Check if the block has already been transformed 
% under 7r. If not, transform it. 
transform (id, tv) 
if ((id, 7r ) G T ) 

return T[(id,n)\ 
idt := next_block() 

T := T\(id,n) H » idt ] 

(stmts, br) := get_block(*d) 
transform_body((sfmfe, br),iv, id, []) 
return idt 
% Evaluate a branch. 
transform_body(([], Jmp b), tv, id, ss) 
idb := transform(6, 7r) 
push_block(id, ss, Jmp idb) 

transform_body(([], If l then t else f),iv,id, ss) 
if vars(l) C I 

dest := if eval(7,7r) then t else / 
iddest '■= transform(dest, 7r) 
push_block(*d, ss, Jmp iddest) 
else 

idt '■= transform(f, 7r) 

idf := transform(/, 7r) 

push_block(id, ss, If l then idt else idf) 

% (Potentially) update an index. 
transform_body(([x = expr|sfmfs], br), n, id, ss) 
if a; € I 

split _transform(iE, (stmts, br), tv, id, ss : :[x = expr]) 
else 

transform_body((s£mts, br),n, id, ss : :[x = expr]) 

% Transform an array read... 
transform_body(([x = A[i] | stmts], br), tv, id, ss) 

At := find_avar(7r, A, i) 

transform_body((simis, br), tv, id, ss : :[x = At)) 

% or an array write. 

transform_body(([A[i] = x|s£m£s], br), tv, id, ss) 

At := find_avar(7r, A, i) 

transform_body((simis, br),iv, id, ss : \[Ai = x]) 

(a) The top-level transformation process 


split_transform(ir, (stmts, br),n, id, ss) 
n' := feasible_orders(7r, oi) 
split_rec(ir, II' , (stmts, br),n, id, ss) 

split_rec(ir, [7/], (stmts, br), n, id, ss) 
asts := remap_avars(7r, 7r') 
transform_body((s£mis, br),iv' , id, ss : : asts) 

split_rec(ir, [7r , |i7 , ] 1 (stmts, br), n, id, ss) 
id n / := next_block() 
id n f := next_block() 
cond := ord_cond(ir, n 1 ) 

push_block(id, ss, If cond then id n i else idn') 
asts := remap_avars(7r, 7r') 
transform_body((sfmfs, br),n', id n / , asts) 
split_rec(r, II' , (stmts, br),n, id n / , []) 

(b) Fan-out of a block when an index variable is changed 


feasible_orders(fc, 7r) : insert(fc, tv, []) 

insert(fc, | ],pre) : return {pre : \{k} : :{fc + }} 
insert(fc, [St\S],pre) 

low := insert + (fc, [St | S],pre: :{k}) 
high ■.= insert (k,S,pre: : St) 
if 3 x . x + G St 

return low U high 
else 

return low U high U 

insert + (fc, S,pre : :(Si U { k })) 

insert + (fc, [],pre) : return {pre: :{k + }} 
insert + (fc, [St \ 5], pre) 
if 3 x . x + G St 

return {pre: :(Si U {fc + }) ::S} 
else 

return {pre: :(Si U {fc + }) : :<S} U 
{pre : :{fc + } : : Si : : S} 

(c) Enumerating the possible total orderings upon 
introducing a new index variable k 


Fig. 6. Pseudo-code for stages of the transformation process. 


block. As a block is processed, instructions not involving index or array vari- 
ables are copied verbatim into the transformed block. During the process, we 
ensure that each (transformed) statement is reachable under exactly one index 
ordering tv. Singleton segments under tv are represented by scalar variables, and 
aggregate segments by set variables. Array reads and writes are replaced with 


vr = [{0} < {1} < {i} < {*+} < {n}] 


transform_body : n 


x := A[i] 
B[i\ := x 
i := i + 1 



(a) Original 


X = a 2 

transform_body : n 

B[i\ := x 
i := i + 1 

(b) After Step 1 


x = a 2 
b 2 := x 

transform_bod; 

/ : tt 


i := i + 1 



(c) After Step 2 


Fig. 7. Transformation of array reads and writes under ordering 7r. As the segment 
[i, i + \ is a singleton, the array elements are represented as scalars. 


accesses and assignments to the corresponding scalar or set variable, as deter- 
mined by find_avar. Conditional branches whose conditions are determined by 
the current ordering are replaced by direct branches to the then or else part, 
as appropriate. Once no instructions remain to be transformed, the block id is 
emitted with body ss, together with the appropriate branch instruction. 

Whenever an index variable is modified, the rest of the current block must 
be split, and the set variables must be updated accordingly. The rest of the 
block is then transformed under each possible new ordering i t' . This is the job 
of split_transform shown in Fig. 6(b), while the job of feasible_orders in Fig. 6(c) 
is to determine the set of possible orders. The function ord_cond(a;, tt’) generates 
logical expressions to determine whether the ordering n' holds, given that 7r 
previously held. ord_cond checks the position of both x and x + . 11 x is part of 
a larger equivalence class in 7r, ord_cond generates the corresponding equality; 
otherwise, it checks that x is greater than its left neighbour; similarly, it checks 
that x + is in its class or less than its right neighbour. Fig. 6(b) shows the process 
of splitting a block upon introducing an index variable x. 


5.1 Reading and writing 

Transformation of array reads and writes is simple, if the array index is in the set 
I of index variables. Fig. 7(a-c) shows the step-by-step transformation of a block, 
under the specified ordering. After Step 1, reference A[i\ has been transformed 
to scalar a 2 , since {i} is a singleton. Similarly, Step 2 transforms B[i\ to b 2 . 

If the index of the read/write operation has been omitted, we must instead 
emit code to ensure the operation is dispatched to the correct set variable. The 
dispatch procedure is similar in nature to split_transform, as given in Fig. 6(c); 
essentially, we emit a series of branches to determine which (if any) of the current 
segments contains the read/write index. Once this has been determined, we 
apply the array operation to the appropriate segment. If the selected segment is 
a singleton, this is done exactly as in transform_body. For writes to an aggregate 
segment, we must first read some vector from the segment, substitute the element 
to be written, then merge the updated vector back into the segment. 4 

4 Detailed pseudo-code for this is in Appendix A. 




*■ = [{0} < {1} < « < {i + } < {«}] 
= [{0} < {1} < {*} < {*+} < M] 

^ = [{ 0 } <{ 1 } <«<{*+, n}] 



Fig. 8. Example of updating an index assignment. We assume an existing scalar anal- 
ysis which has determined that, after i = i + 1, we have 1 < i < n. 


5.2 Index manipulation 

The updating of index variables is the most involved part of the transformation, 
as we must emit code not only to determine the updated ordering 7 r', but also 
to ensure the array segment variables are matched to the corresponding bounds. 
Fig. 8 illustrates this process, implemented by the procedure remap_avars, as 
it splits a block into three: one to test an index expression to determine what 
ordering applies, and one for each ordering. In the original code, ordering tt ap- 
plies, but following the assignment, either ordering ir' 0 or 7r( may apply. The test 
inserted by Step 2 distinguishes these cases, leaving only one ordering applicable 
to each of the sy< and split i blocks. 

If we normalize index assignments such that for k := E, k ^ E, we can 
separate the updating of segment variables into two stages; first, computing in- 
termediate segment variables A' t after eliminating k from 7r, and then computing 
the new segment variables after introducing the updated value of k. Pseudo-code 
for these steps are given in Fig. 9(a) and 10(a). In practice, we can often elim- 
inate many of these intermediate assignments, as segments not adjacent to the 
initial or updated values of k remain unchanged. 







7T = 


remap_avars(fc, n, ir') 

eliminate^, n) :: introduce^, 7r') 

eliminate^, 7r) 

eliminate^, n, 0 , 0 , 0) 

eliminate^, [], i', E) 

if (?' = 0) return [] 
else return [emit_merge(^4',_ 1 , E)] 

eliminate^, [{c} | S\,i,i',E) 
where c G {k, fc + } 

return eliminate^, S, i + 1, i' , E U {Hi}) 

eliminate^, [Sj \ S],i,i',E ) 

suff := eliminate^, S,i + l,i' + 1, {A^}) 
if(i' = 0) 

% Ignore leading segment. 

return suff 
else 

return emit_merge( J 4'/_ 1 , E) : : suff 

emit_merge(a;, E) 
return [x = (j£7] 


ao a i 

[{fc} < {k+,n} < {n+}] 
a'o 

n r = [{n} < {n+}}] 


clq : — a i 


ao 


7r = [{fe, n} < {k + , n + }] 
a o 

^ = [{n} < {n+}}] 


a 0 := a 0 


a o a i A2 03 

7r = [{i} < {i + , k} < {fc + } < {n} < {n + }] 

Oq A 3 0<2 

T3 r = [{*} <{*+}< {n} < {n+}] 


a 0 * — no 
A' x •= {ai} U An 
a'n ■■= a 3 
(b) 


Fig. 9. (a) Algorithm for generating instructions to keep segment variables updated; 
(b) resulting assignments when k is eliminated from various orderings, also showing 
the remaining order Tv r and scalar or set variables corresponding to each segment. 


When we eliminate an index variable k from 7 r, we merge segments that were 
bounded only by k or k + . If k or k + appears alone at the very beginning or 
end of 7 r, the segments are discarded entirely. If either appears alone between 
other variables in 7 r, the segments on either side are merged to form a single 
segment. However, if k and k + are both equal to some other variables, the 
original segments are simply copied to the corresponding temporary variables. 
This is illustrated in Fig. 9(b). 

The pseudo-code in Fig. 9 and 10 ignores the distinction between singleton 
and aggregate segments; the transformed operations differ slightly in the two 
cases. If we introduce a singleton segment into an aggregate segment, we select 
a single vector from the set (( a b' , d) = nondet-elt(H)); if an aggregate segment 
is introduced, we emit a subset operation (A' = nondet-subset(A)). 

The procedure for injecting k into 7 r behaves similarly. If k is introduced 
at either end of 7 r, we introduce new segments with indeterminate values. If k 


7T P = [{n} < {n+}] 

7r = [{£;} < { k + , n} < {n + }] 


ao * 
ai := a' 0 


7T P = [{n} < {n+}] 

7r = [{fc, n} < {fc + , n + }] 


a 0 := d^ 


vrp = [ W <{,;+}< {n} < {n+}] 

7r = [{i} < {i + , fe} < {fc + } < {n} < {n + }] 


Fig. 10. (a) Generating instructions for (re-)introducing a variable k into a given or- 
dering, and (b) the resulting assignments when k is introduced into various orderings. 
Note the difference between introducing singleton and aggregate segments. 


d 0 := d 0 

(di) = nondet-elt(A' 1 ) 

A 2 = nondet-subset(A , 1 ) 
d 3 := a’ 2 

(b) 


introduce^, n) 

introduce(fc, n, 0, 0) 

introduce^, [], *') 

return [] 

introduce^, [{c} | *') 

where c € {fc, k + } 
suff := introduce(fc, S, i + 1, i') 
if(i' = 0) 

return \Ai = *] : : suff 
else 

return [A, = nondet-subset(A')] : : suff 
introduce(fc, [Sj \ 

suff := introduce^, S, i + 1, + 1) 

if(i' = 0) 

% Ignore leading segment. 

return suff 
else 

return [ Ai = A',] : : suff 
(a) 


is introduced somewhere within an existing segment, we introduce new child 
segments — each of which is a subset of the original segment. 

5.3 Control flow 

When transforming control flow, there are three cases we must consider: 

1. Unconditional jumps 

2. Conditional jumps involving some non-index variables 

3. Conditional jumps involving only index variables 

In cases (1) and (2), the transformation process operates as normal; we re- 
cursively transform the jump targets, and construct the corresponding jump 
with the transformed identifiers. However, when we have a conditional jump 
If itxdj then t else / where i and j are both index terms, the relationship 
between i and j is statically determined by the current ordering ir. As a result, 
we can simply evaluate the condition fcxij under the ordering n, and use an 
unconditional branch to the corresponding block. This is illustrated in Fig. 11. 


tt = [{0} < {1} < {i} < {*+} < n] 



Fig. 11. Transforming a jump, conditional on index variables only, under ordering it 

6 Selecting segment bounds 

Until now we have assumed a pre-selected set of interesting segment bounds. 
The selection of segment boundaries involves a trade-off: we can improve the 
precision of the analysis by introducing additional segment bounds, but the 
transformed program grows exponentially as the number of segment bounds 
increases. As do [11], we can run a data-flow analysis to find the set of variables 
that may (possibly indirectly) be used as, or to compute, array indices. Formally, 
we collect the set I of variables and constants i occurring in these contexts: 

A[i] where A is an array (2) 

i' = op( i) where i' G I (3) 

i = op {i') where i' € I and i' is not a constant (4) 

Any variable which does not satisfy these conditions can safely be discarded as a 
possible segment bound. For the experiments in Section 7 we used all elements of 
I as segment bounds (so 1 = 1), which yields an analysis corresponding roughly 
to the approaches of [9, 11]. We could, however, discard some subset of I to yield 
a smaller, but less precise, approximation of the original program. The cases (3) 
and (4) are needed because of possible aliasing; this is particularly critical in 
an SSA-based language, as SSA essentially replaces mutation with aliasing. It is 
worth noting that these dependencies extend to aliases introduced prior to the 
relevant array operation, as in the snippet “i := x; ... A[i\ := k; ... y := x + 1;” 

7 Experimental evaluation 

We have implemented our method using the LLVM framework, in two distinct 
transformation phases. In a first pass, transformation is done as described above, 
but without great regard for the size of the transformed program. At the same 
time, we also use a (polyhedral) scalar analysis of the original program (treating 
arrays as unknown value sources) to detect any block whose total ordering is 
infeasible. In the second pass, we prune these unreachable blocks away. As can be 
gleaned from Table 1, these measures reduce the complexity of the transformed 
program significantly. 





To extract array properties from the 
corresponding invariants discovered in a 
transformed program, we require users to 
specify, at transformation time, the range 
of array segments that are of interest. In 
our implementation, this is described by 
a strict index inequality that must ap- 
ply to segments in the range. For exam- 
ple, specifying 0 < n indicates that we 
are interested in invariants of the form 
W (0 < t < n =► A k [£])), 

where A \ , . . . , Ak are the arrays in scope 
and ip is some property. At the end of the 
transformation we use a newly created 
block to join all copies of the original exit 
block whose total ordering is consistent 
with the given range. The various scalar 
representations for each array segment, 
as well as other variables in scope in each 
copy, are merged together in phi nodes 
inside this final block. Properties discov- 
ered about the segment phi nodes then 
translate directly to properties about the 
corresponding array segments in the orig- 
inal program. 

We have tested our method by run- 
ning first the polka polyhedra do- 
main [12] on the output of our trans- 
formation when applied to the programs 
given in Fig. 12. The interesting invari- 
ants that we infer are as follows (each 
property holds at the end of the corre- 
sponding function): 

array _copy : W (0 < i < n => A[£\ = B[t]) 

arrayinit : W (0 < t < n => A[l] = 5) 

array _max : W (0 < l < n => A[t] < max ) 

search : Mi (0 < l < i => A[t] ^ key) 

first_not_null : W (0 < t < s A[t] = 0) 

sentinel : (0 < t < i => A[t] ^ sent) 

Fig. 12 shows test programs from related papers [9, 11]. Table 1 lists sizes of the 
original, transformed, and post-processed transformed versions (columns Origi- 
nal, Transformed, and Post-processed respectively), as well as the time to per- 
form the transformation (column transf). Column polka shows the analysis time 
in seconds for running the polka polyhedra domain, uva is explained below. 



Fig. 12. Simple test programs 




Program 

Original 

Transformed 

Post-processed 

Running time (s) 

blocks 

insts. 

blocks 

insts. 

blocks 

insts. 

transf. 

polka 

uva 

array _copy 

5 

12 

274 

898 

33 

149 

0.80 

67.07 

0.18 

array Jnit 

5 

11 

274 

644 

33 

115 

0.94 

19.08 

0.22 

array _max 

7 

19 

220 

562 

51 

139 

0.95 

110.87 

0.45 

search 

5 

10 

90 

167 

27 

69 

0.49 

2.05 

2.75 

first _not_null 

8 

17 

1057 

2217 

216 

694 

3.73 

2378.35 

4.85 

sentinel 

5 

13 

1001 

1936 

294 

765 

3.07 

1773.01 

4.97 


Table 1 . Sizes of transformed test programs and analysis time for polka and uva 


Enhancing an existing analyzer. As a separate experiment we use IKOS [3], 
an abstract interpretation-based static analyzer developed at NASA. IKOS has 
been used successfully to prove absence of buffer overflows in Unmanned Aircraft 
Systems flight control software written in C. The latest (unreleased) version of 
IKOS provides an uninitialized variable analysis that aims at proving that no 
variable can be used without being previously defined, otherwise the execution 
of the program might result in undefined behaviour. 

Currently IKOS is not sufficiently pre- 
cise for array analysis. (Fig. 13), IKOS 
cannot deduce that A [5] is definitely 
uninitialized at line 4. However, us- 
ing the transformational approach, IKOS 
proves that A [5] is definitely uninitial- 
ized. The problem is far from trivial; as 
Regehr [17] notes, gcc and clang (with 
- Wuninitialized ) do not even raise warn- 
ings for this example, but stay completely 
silent. 

We ran IKOS on the transformed version of array _init_unsafe. IKOS success- 
fully reported a definite error at line 4 in 0.22 seconds. Conversely, transformation 
enabled IKOS to show that no array element was left undefined in the case of 
array Jnit. Finally we ran IKOS on the rest of the programs in Fig. 12. For the 
purpose of the uninitialized variable analysis we added loops to force each array 
to be treated as initialized, when appropriate. For the transformed version of 
array _copy, IKOS proved that A is definitely initialized after the execution of 
the loop. For the rest of the programs IKOS proved that the initialized array A 
is still initialized after the loops. Column uva in Table 1 shows the analysis time 
in seconds of the uninitialized variable analysis implemented in IKOS. 

Note that the polka analysis does not eliminate out-of-scope variables. Our 
program transformation introduces many variables, and since polka incurs a 
super-linear per-variable cost, the overall time penalty is considerable. We expect 
to be able to greatly reduce the cost by utilising a projection operation and 
improving the fixed-point finding algorithm. 


int array Jnit_unsafe (void) { 
1: int A[6], r, 

2: for (i = 0; i < 5; *++) 

3: A[i] = 1; 

4: return A [5]; 

} 


Fig. 13. Regehr’s example [17] 





8 Related work 


Amongst work on automated reasoning about array-manipulating code, we can 
distinguish work on analysis from work that focuses on verification. Our paper 
is concerned with the analysis problem, that is, how to use static analysis for 
automated generation of (inductive) code invariants. As mentioned in Section 1, 
we follow the tradition of applying abstract interpretation [4] to the array con- 
tent analysis problem [5,9,11,16]. Alternative array analysis methods include 
Gulwani, McCloskey and Tiwari’s lifting technique [10] (requiring the user to 
specify templates that describe when quantifiers should be introduced), Kovacs 
and Voronkov’s theorem-prover based method [13], Dillig, Dillig and Aiken’s 
fluid updates [7] (supporting points-to and value analysis but excluding rela- 
tional analyses), and incomplete approaches based on dynamic analysis [8, 15]. 

Unlike previous work, we apply abstract interpretation to a transformed pro- 
gram in which array reads and writes have been translated away; any standard 
analysis, relational or not, can be applied to the resulting program, with negli- 
gible additional implementation cost. 

There is a sizeable body of work that considers the verification problem for 
array-processing programs. Here the aim is to establish that given assertions hold 
at given program points. While abstract interpretation may serve this purpose 
(given a well-chosen abstract domain), more direct approaches are goal-directed, 
using assertions actively, to drive reasoning, rather than passively, as checkpoints. 
Many alternative techniques have been suggested for the verification of (some- 
times restricted) array programs, including lazy abstraction [1], template-based 
methods [14], and, more closely related to the present paper, techniques that 
employ translation, for example to Horn clauses [6]. 

9 Conclusion 

We have described a new abstract machine that supports set- valued variables and 
shown how array manipulating programs can be translated to array-free code for 
this machine. By compiling array programs for this machine, we are able to dis- 
cover non-trivial universally quantified loop invariants, simply by analysing the 
transformed program using off-the-shelf scalar analysers. As an example of how 
this allows an existing analysis to be lifted to array programs in a straightforward 
manner, we have extended an uninitialised-variable analysis; Figure 13 showed 
the usefulness of this approach. The indisputable price for the ease of imple- 
mentation is a potentially excessive size of the transformed program. However, 
much array-processing code tends to make simple array traversals and access, 
and the transformational approach is viable for more than just small programs. 
Future work includes performing the transformation lazily, to avoid generating 
unneeded blocks. This should significantly speed up the analysis. 
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Appendix A: Array operations with non-segment variables 


Fig. 6(a) assumes that the index variable of every read or write is included in 
the set of segment bounds. Fig. 14 gives a revised version of transform_body 
which handles writes to indices that are not included in the set of segment 
bounds. When we transform a write to an index in the set of segment bounds 
(determined by the predicate isJdx), the transformation is as usual. Otherwise, 
we emit code to walk through the current set of segments, and apply the write 
operation to the appropriate one. The dispatch process is similar to the operation 
of split_transform, except that all leaves jump back to the continuation of the 
basic block after the write, rather than continuing under the modified ordering. 


transform_body(([A[i] = x| stmts], br), n, id, ss ) 

if is_idx(i) 

A t := find_avar(7r, A, i) 

transform_body( (stmts, br),n, id, ss : :[Ai = x]) 
else 

id' := next_block() 
transform_body((stmts, br),ir, id' , []) 
dispatch_write(A[i] = x, e, n, id, ss, id') 

dispatch_write(A[i] = x, sv, [], id, ss, id') 
push_block(id, ss, Jmp id') 

dispatch_write(A[i] = x, s < , [p, . . .|7r], id, ss,id') 
id> := next_block() 
id = := next_block() 
s = := next_svar(s<) 
s> := next_svar(s = ) 
if s< = e 

push_block(id, If i < p then id' else id>, ss) 
else 

id< := next_block() 

push_block(i<i, If i < p then id< else id>, ss) 
push_block(id < , Jmp id', 

[{vi,...,v A ,-.-,v k ) G s<, 
s< = s< U{(ui,...,a;,...,Ufc)}]) 
push_block(i<i>, If i = p then id= else id > ,id = ,id > ) 

(...,v A ,---) ■■= s = 

push_block(id = , Jmp id ' , [v A = #]) 
dispatch_write(A[i] = x,s > ,n,id > , [],id') 


Fig. 14. Revised pseudo-code for transforming array writes, allowing for omitted in- 
dices. Array reads are transformed similarly. 





